【登壇資料】AWS CDK を使った サーバーレスアプリケーションのデプロイ方法と実装例を紹介しました – Developes.IO 2020 CONNECT #devio2020

AWS サーバーレスアプリケーションデプロイのハードルを下げたい

プロダクションでのアプリケーション構築にサーバーレスを採用することも増えてきました。本セッションではサーバーレスアプリケーションのデプロイを考えます。昨今のクラウドアプリに共通して、デプロイのハードルがかなり上がっています。実際の環境、例えばAWSにあげてみないとわからないことが増えてきたためです。

プロダクションデプロイのハードルを下げるアプローチとして、「デプロイ可能な状態を維持する」方針を立ててみました。そして、そのために AWS CDK が寄与することを述べました。さらに、実際にいくつかの実例を交えて、AWS 構成、その際の AWS CDK コードを説明しました。

発表のポイント

一貫した方針は、 開発スタートの最初にデプロイ可能な状態を作ってしまい、それを維持すること です。

サーバーレスでいくかどうか決める

こういうタイトルで何ですが、どうやってデプロイするかの前に、サーバーレスでアプリケーションを構築するかどうか考える必要があります。なぜならこの選択は 開発の流れとコスト体系が変わる ことになり、技術だけに閉じた話ではないためです。正しい、正しくないというよりは、関係者全員の合意と納得が必要になります。

サーバーレスで、となったらまずはデプロイ！ でもなんで AWS CDK？

一言でいうと、開発作業における 「開発」部分と「デプロイ」部分の垣根を極限まで小さくしてくれるツールだからです。アプリケーションコードとしてTypeScrtiptを採用すると、さらに実感できます。 TypeScript は AWS CDK の開発言語でもあるからです。

デプロイを便利にしてくれる構成管理ツールはたくさんあります。AWS CloudFormation の テンプレートや AWS SAM, Serverless Framework, Terraform など構成管理ツールがある中、AWS CDK を選ぶ理由はなんでしょうか。私は、最初に AWS CDK の仕組みをみたとき、AWSからの強烈なメッセージを感じました。それは…

やります。

デプロイまでの流れと、いくつかの実装パターンを紹介

AWS CDK からのメッセージを噛み締めつつ、いくつかの実装例を交えてその便利さをお伝えしました。

デプロイを試したくなったら

サンプルリポジトリを用意しています。興味があれば触ってみてください。

• cm-wada-yusuke/template-aws-cdk-typescript-serverless-app

QA

たくさんの質問ありがとうございました。実装寄りの質問が多く、聞いてほしい方々に聞いてもらえたのだと、嬉しかったです。

Q.CDKでIAMが自動生成されるというのですが、どのような内容になるのでしょうか。ブラックボックスになるとセキュリティ的に不安です。

基本的には動作させるための最小ポリシーのIAMロールが生成されます。不安な場合は AWS CDK 上で new iam.Role() のように明示的に IAM ロールを作り、それを Lambda Function などにアタッチすることも可能です。IAM Role を明示的に定義するケースで気をつけたいのは逆のパターンで、ポリシー不足で動かない、という状況に私はしばしば遭遇しました。

たとえば Lambda Function から Amazon Athena を使って insert into しようとしたとき、athena/* リソースだけでなく glue/* リソースに対しても書き込み許可が必要だった、ということがありました。

A.CDK 自体は TypeScript で書くことがほとんどだと思いますが、 Lambda 関数のランタイムについて TypeScript (Node.js) で統一することのほうが多いのでしょうか。

チーム状況や案件状況によって異なりますが、 AWS CDK を採用しているチームは、 Lambda Function の実装言語にも TypeScript を採用しているケースが多い印象です。参考までに、CX事業本部の実装言語アンケート結果を載せておきます（2020年6月11日時点）。

CX事業本部全メンバーがサーバーレス開発に携わっているわけはなく、むしろモバイルアプリケーション、SpringBootなどを利用した開発が大多数です。そんな中でも TypeScritp を採用しているメンバーが多いというのは、例えばフロントエンドの実装言語としても使えるし、サーバーサイドの一部に Lambda Function を導入するケースでも、TypeScript を使うことが多いのかもしれません。

Q. (CDK の仕様に?) 破壊的な変更が起こった場合は運用に支障があると思うのですが、どのような対応で回避されていますでしょうか

開発中であればプルリクとプルリクの間に積極的にアップデートをはさみます。リリース後の本番稼働中は、ビジネスロジックの変更や修正が発生し、デプロイするタイミングで AWS CDK のバージョンも上げてしまうことがおすすめです。このとき、デグレなどが気がかりですが、そちらは E2Eテスト で安心感を保証する形が良いと考えています。サーバーレスのテスト戦略については、私が ServerlessDays Fukuoka 2019 にて発表した資料がありますのでそちらをご覧ください。

Q. stepfunctionsとSimpleWorkFlowとの使い分けについて、どのような使い分け（例など）ができるか教えていただけますでしょうか？

Amazon Simple Workflow Service (SWF) は使ったことがないのでわかりません！ごめんなさい。以下は公式ドキュメントの引用です。

Q: AWS Step Functions とAmazon Simple Workflow Service (SWF) はどのように使い分けますか?

AWS Step Functions では、より生産的かつ機敏なアプローチにより、視覚的ワークフローを使用してアプリケーションコンポーネントを調整できるため、新しいアプリケーションには AWS Step Functions を使用することをお勧めします。プロセスにおいて介入する外部信号が必要な場合、または結果を親に返す子プロセスを起動する場合は、Amazon Simple Workflow Service (Amazon SWF) を使用してください。Amazon SWF では、宣言型の JSON にステートマシンを記述するのではなく、ディサイダープログラムを書いて決定ステップからアクティビティステップを分離します。Amazon SWF では、連携ロジックを完全に制御することが可能ですが、アプリケーションの開発はより複雑になります。選択したプログラミング言語でディサイダープログラムを記述することも、フローフレームワークを使用して、自動的に非同期の相互作用を構造化するプログラミングコンストラクトを利用することもできます。 よくある質問 - AWS Step Functions | AWS https://aws.amazon.com/jp/step-functions/faqs/

Q. CDKの単体テストはどの程度の粒度で記述していますか？

主に Fine-grained assertinos、つまり CloudFormatin のリソースが意図どおり生成される予定かどうかをテストしています。

• Testing constructs - AWS Cloud Development Kit (AWS CDK)

ただしすべてのリソースを網羅することはしておらず、例えば AppSync の大元が生成されているか、 API Gateway の大元が生成されているか、程度です。これにはいくつか理由があり、

• AWS CDK をデプロイする前にリソースの増減については表示してくれるから（その後 yes/no でデプロイ是非を判断できる）
• デプロイ作業そのものでデプロイ可能性についてはテストできており、なおかつデプロイしたAWSリソースの挙動については アプリケーション側のテストでまかなえることも多いから
  • 例えば API Gateway の特定のAPIにリクエストを送り、そのレスポンスを確認する E2Eテストなど、です

ということで、コスパの面から意図的に AWS CDK の単体テストについては優先度をいたずらに上げないようにしています。もちろん、すべてのリソースについて、 Fine-grained assertions が行えるならばそれに越したことはないです。時間との相談ですね。

Q. 今、serverlessFrameworkを使用しているのですが、乗り換えコストを負ってでもAWSCDKへ移行する理由はあるでしょうか？

Serverless Framework も素晴らしいツールなので、現時点で特に困りごとがないのであれば乗り換える必要はありません。

Q. cdk projectをdeployするCI/CDのパイプラインリソースもcdkで管理されていますか？

はい、 パイプライン自体も AWS CDK で管理しています。Lambda Function などのアプリケーションと比べて、デプロイ頻度は少なく、かつデプロイサイクルも異なるので、 別スタック または アプリケーション（AWS CDKの世界の話） を分け、別々にデプロイできるようにしておくことをおすすめします。一度作っておくと、いろいろなプロジェクトで流用できますね。

AWS Codepipeline を定義する部分のコードは、こんな感じになります。

Q. サーバーレスは便利ですが、誤解されがちな技術スタックでもあると思います。例えば「サーバーレス使えば安くなるんでしょ？」というお客様とどういう会話をしますか？

こちらは クラメソマーケ部の嵩原さんからの質問ですね。ありがとうございます。まずサーバーレスに興味をもっていただいている時点でラッキーではあるのですが、おっしゃるようにちょっと誤解しているケースも少々あります。この状況では、関係者全員が納得するまで以下のことを共有します。それまでは手を動かしません。

• 安価になるのは「使った分だけ課金」特性によるコスト最適化の副次的な結果にすぎず、予算がシビアで見積もりを正確に行わなければならないならば、むしろ採用するべきではない
• サーバーレスアプリケーションは一度本番稼働させれば終わりではなく、市場の動向に合わせて都度追加開発が行える点が強み。繰り返し開発を行える体制が組めるか？都度、追加開発を行う価値のある投資対象か？
• ビジネスサイドと開発サイドが共闘する体制を組めるか？

これらがクリアできるならば、変化に強い モダンアプリケーションが組めるはずです。

7月3日（金）はモダンアプリケーション特集です！

7月3日（金）のDevelopersIO 2020 CONNECT はサーバーレスと、このセッションでは触れなかったコンテナによるモダンアプリケーション特集です。奮ってご参加ください。

Developers.IO 2020 CONNECT全オンラインセッションのご紹介 ｜ Developers.IO